In 1992, the United States Postal Service (USPS), acting largely on a formal December 1991 proposal by the inventor, began investigating the feasibility of PC-based postage technology. The USPS hosted an exploratory meeting, inviting the inventor and the four existing conventional postage meter vendors (Pitney Bowes, Neopost (called Friden at the time), Ascom Hasler, and Franco Postalia)—firms that represented 100% of the US meter market at that time. Subsequent years saw a number of follow-on meetings, and the USPS eventually published a specification in the 1996 Federal Register outlining what the USPS called an “Information Based Postage Indicium Program (IBIP).” The requirements for the IBIP are currently set forth in a document called “Information Based Indicium Program (IBIP)—Performance Criteria For Information-Based Indicia and Security Architecture for Open IBI Postage Evidencing Systems (PCIBI-O),” which was published on Jun. 25, 1999 by the USPS, and which is fully and expressly incorporated herein by reference.
Two different types of PC-based postage architectures have evolved. The first type of architecture is a distributed postage indicia generation system, an example of which is detailed in U.S. Pat. No. 5,319,562, entitled “System and Method for Purchase and Application of Postage Using Personal Computer,” which is expressly and fully incorporated herein by reference. In this system, lump sums of postage are purchased and downloaded via a telecommunications link to a local secure computational device at the end user's location. In USPS jargon, this device is called the Postal Secure Device (PSD). Typically, these postage transfers range from fifty to several thousand dollars. This amount is added to whatever balance remains in the PSD. The end user may then draw upon the balance in the PSD to produce postage indicia of varying amounts and service classes that are printed on mail pieces. As the mail pieces are individually metered (or in the case of the IBIP, created and simultaneously “metered”), the balance in the PSD is decremented by the transaction amount (e.g., 34 cents). The second type of architecture is a centralized postage indicia generation system, an example of which is detailed in U.S. Pat. No. 6,005,945, entitled “System and Method for Dispensing Postage Based on Telephonic or Web Milli-Transactions,” and which is fully and expressly incorporated herein by reference. In this system, the end user's account balance is securely stored in a centralized postage-issuing computer system, and the end user contacts the centralized postage-issuing computer system each and every time postage is to be applied to a mail piece.
Referring to FIG. 1, a typical IBIP mail piece 100 printed using either the distributed or the centralized postage indicia architecture is shown. The mail piece 100 comprises an envelope 102 on which various items are printed. A postage indicium 104 (in layperson's terms, a “stamp”), as applied by a computer printer, is located in the upper right hand corner of the envelope 102. The postage indicium 104 comprises a two-dimensional barcode 106 containing data relating to the mail piece 100 and the account holder, as well as human-readable information 108, e.g., the data, account number and amount of postage. The USPS has currently approved Portable Data File (PDF) and DataMatrix 2-D barcodes. Facing Identification Marks (FIM) 110 are located at the top of the envelope 102 above and to the left of the postage indicium 104, and are used by the USPS for the initial sortation of letter mail. The significance of the FIM 110 in letter mail processing is described in U.S. Pat. No. 5,319,562. A return address 112 and destination address 114, which are self-evident, are printed on the face of the envelope 102. A POSTNET barcode 116, which is located beneath the destination address 114, represents the delivery point ZIP code of the destination address. The delivery point ZIP code is an 11-digit code, only 9 of which are shown on the last line of the destination address 114. The last two digits of the delivery point ZIP code are generally derived from the last two digits of the street address number, which in the illustrated embodiment, is “47.”
The amount of data in the postage indicium 104 is substantial and was designed with a distributed postage indicia generation system in mind. Significantly, in a distributed postage indicium generation architecture, the USPS has no detailed knowledge of how the postage is consumed. For example, for a hypothetical $100 of postage downloaded, the end user could create ten postage indicia of a $10 valuation, two hundred indicia of 50-cent valuation, or a combination thereof. In reality, the number of permutations is far greater. The USPS approach to this problem was to create a postage indicium with sufficient information, so that its authenticity could be determined in the absence of any other information. In other words, the USPS sought a “stand-alone” system that would be verifiable using only the human-readable information on the mail piece 100 and the data encoded in the two-dimensional barcode 106 of the postage indicium 104. In theory, no other “outside” information would be necessary. Table 1 sets forth the current IBIP postage indicium contents, including the field name and byte size of each content item.
TABLE 1Current IBIP Indicium ContentsItem NumberField NameSize (Bytes) 1Indicia Version Number1 2Algorithm ID1 3Certificate Serial Number4 4Device ID8 5Ascending Register5 6Postage3 7Date4 8License ZIP4 9Destination ZIP510Software ID611Descending Register412Rate Category413Signature40 14Reserved (Vendor Specific Information)115Piece Count (Vendor Specific Information)4
Thus, the date (item #7) embedded in the barcode portion of the postage indicium 104 could be compared to the current date, as well as to the human-readable date. The postage amount (item #6) embedded in the barcode portion 106 of the postage indicium 104 could be compared to the human-readable postage amount, and for United States addresses, the delivery point ZIP code (item #9) embedded in the barcode portion 106 of the postage indicium 104 could be compared with the delivery address 114 printed on the mail piece 100. Should any of these “information pairs” show an inconsistency, the mail piece 100 would be immediately suspect and would be a candidate for further investigation.
The “veracity” of the invention in the barcode portion 106 of the postage indicium 104 was to be validated by public key cryptography, which was first disclosed by Diffie and Hellman in 1976, and essentially involves the use of a matched pair of public and private key components to either encrypt or digitally sign data. The keys are extraordinarily large integer values that have interesting cryptographic capabilities. Briefly, the public key component can be used to encrypt material, or verify a digital signature created by the corresponding private key. The private key component can be used only to create digital signatures that can be verified by the public key. Importantly, the public key component can be widely disseminated and in fact “published,” because it is virtually impossible to infer the corresponding private key component. In cryptographic terms, it is “computationally infeasible” to infer the private key component given the public key component provided the modulus or size of the key is of sufficient size. Given the computational speed of computers available at the time of this writing, key sizes of 1024 or 2048 bits are considered highly secure.
In the USPS implementation, public key encryption is not used, but rather the private key component is used to digitally sign data. For example, as illustrated in Table 1, a private key component is used to digitally sign the first twelve items contained in the postage indicium 104 to generate a digital signature (item #13), which digital signature is then appended thereto. In the USPS model, each end user (i.e., meter account) has a unique public/private key pair assigned to him or her. The private key component is never divulged to the end user, but is stored securely in the PSD at the end user's site. The PSD digitally signs the data, i.e., the information associated with the postage indicium request. The matching public key component can then be used to validate the signature. A more detailed discussion of how public key cryptography is used in the IBIP is disclosed in U.S. Pat. No. 6,005,945.
Despite the commercial potential of the IBIP, it languished in uncertainty for several more years until two vendors were approved for beta testing in August of 1998. The companies, EStamp and Stamps.com, were relative newcomers to the PC-postage effort. Both firms finished beta testing approximately one year later (the fall of 1999). Pitney Bowes, the dominant conventional manufacturer, and Neopost were approved several months later. A host of high-value IPO's, based on vastly overstated market potential, funded the EStamp and Stamps.com efforts during the late 1990's. Significantly, as the year 2001 draws to a close, EStamp has withdrawn from the postage business, Stamps.com is encountering several financial and legal problems, and the IBIP is in disarray. During their existence, the foregoing two firms consumed nearly one billion dollars in venture capital and public investment funds attempting to make PC-postage a viable business. In sum, two extraordinarily well-funded vendors have been driven out of the business, the established manufacturers of postage meters have curtailed or delayed their entry into the PC-Postage arena, and end users who were hopeful that this technology would save them time, money, and frustration were deeply disappointed. There are a host of factors that have contributed to the failure of the IBIP to date.
First, the USPS has insisted on developing a “perfect” security model before embarking on limited, alpha-level field-testing to identify “real world” problems. Second, the USPS has emphasized envelope printing, which, due to unyielding USPS mail processing requirements, proved to be very difficult to produce on desktop printers. This was especially true for courtesy reply envelopes provided by utilities and credit card firms, for example, because not only was the envelope difficult to feed and position, but there was a conflict in certain mail processing markings, especially the Facing Identification Code (FIM). Third, the focus on the consumer market with the promise of large numbers ended up costing the initial vendors large sums of money to acquire these customers, which did not provide sufficient financial returns. Fourth, the USPS was slow to appreciate and embrace a host of fraud prevention and detection enhancements inherent to centralized postage dispensing systems. Fifth, there is a lack of single piece discounts for IBIP postage users, even though the addressing and automation requirements imposed by the IBIP are comparable with other discount mailings (such as First Class Presort mail), and even though the discount was repeatedly recommended by the Postal Rates Commission.
Sixth, the public key infrastructure (PKI) approach adopted by the USPS has fallen short on many fronts. The first PKI-related problem surfaced immediately after the USPS published the initial IBIP specification in 1996. In order to provide a “stand-alone” verification system, barcode portion 106 of the postage indicium 104 would not only contain the items shown in Table 1, but would also have to carry the associated public key information for that account. The data in Table 1 is represented by 96 bytes. Because the public key component for a 1024 bit DSA key pair is 128 bytes long, however, adding the public key component for stand-alone verification caused the postage indicium 104 to be over twice the size of the current IBIP version. Comparable public key lengths are seen in the other USPS-approved key pairs such as RSA and elliptic curve.
But the postage indicium 104 needed to be still larger to achieve the goal of stand-alone verification, because the public key component itself must be verifiable. To understand why, suppose an adversary generated her own public/private key pair. This is a very easy process for an entry-level cryptographic programmer. Then she could create a mail piece, generate indicium data with fraudulent account information, digitally sign that information with a private key, and then append the public key to the end of the indicium data. To a verifying party in a stand-alone environment, everything would seem to be in order if one trusted the public key component.
This problem can be solved by using a Certificate Authority (CA), which is a very trusted party (e.g., a government agency or a private firm such as Verisign) who will accept a public key component generated by a third party, investigate that party to ascertain that they are who they say they are, and upon approval, digitally sign the public key with a master private key maintained by that CA. Thus, if the verifying party has the public key component of the CA available in the stand-alone verification system, it can be used to verify the digital signature on the account-specific public key component. If that verification is successful, the account-specific public key can be used to authenticate the postage indicium 104.
The advantage of this approach is that a single master CA public key can be used to ascertain the veracity of millions of other public keys. The disadvantage is that not only is a 128-byte account-specific public key required in the postage indicium 104, but the digital signature generated by the CA adds another 40 to 128 bytes of information. In addition, the CA typically embeds other information in the signed package, including the name of the party and the range of dates for which the account-specific public key is valid. The complete package is called a digital certificate and can grow to a size of several thousand bytes depending upon how many intermediate CA's are involved. The indicium data stream initially proposed by the USPS approached 500 bytes, and the associated two-dimensional bar code portion 106 of the postage indicium 104 covered approximately 25% of the area of a typical commercial #10 envelope. The mailing community and potential IBIP vendors resoundingly rejected this as completely unworkable.
The inventor (and presumably other potential IBIP vendors) proposed an alternative approach to the USPS, which brought the postage indicium down to the current 100 bytes. Rather than including a large digital certificate, a unique 4-byte numerical key pair ID (item #3 in Table 1) would be included instead. The key pair ID then references a complete CA-signed, account-specific public key that the USPS can distribute to field verification staff via CD-ROM or other means. Essentially, each verification staff member would have a database of CA-signed public keys indexed by a key pair ID. When scanning postage indicium 104, the key pair ID would be used to look up the appropriate public key, and that key would be used to verify the digital signature in the postage indicium 104.
While solving the space problem on the mail piece, the inclusion of a key pair ID within the postage indicium 104 did present the USPS with a new problem of distributing public keys to its field staff. This proved to be a daunting task, as some vendors were signing up thousands of new end users per month, each of whom represented a public key that needed to be distributed to every field verifier if the goal of stand-alone verification was to be achieved. Thus, the second major PKI-related problem encountered by the USPS and the IBIP vendors was the cost and logistical issues associated with managing hundreds of thousands, if not millions, of key pairs. IBIP vendors were charged for each key pair certified by the USPS CA. The cost, $8.00 US, was substantial for a PC postage service that had a price point as low as $1.99/month. Furthermore, the USPS had to maintain the database of public keys, deal with the revocation and reissuing of public keys as they expired, and handle other issues associated with the PKI.
In 1998, the inventor suggested another approach to key management in centralized postage systems, which is disclosed in U.S. Pat. No. 6,005,945. Stated briefly, this approach uses a single key pair to service the entire user community for a given centralized postage vendor. The key pair might change daily, weekly or monthly for security reasons, but the net effect would be that only dozens of keys would be employed as compared to millions. We hasten to reiterate that this approach is feasible only when the postage indicia are created at the centralized server cluster run by the postage vendor. That is, the safety of the private key can be assured since it is in the possession of the trusted postage vendor, and not the end user. It should be noted that even the centralized system postage vendor does not have direct knowledge of the private key material. USPS design guidelines require that private key material can only be presented “in the clear” within the confines of a FIPS-140 coprocessor device at the centralized server cluster. This is to prevent “insider attacks” from compromising the private signing key material.
Distributed-architecture IBIP systems that use a local “vault” attached to a PC at an end user's site, or newer stand-alone meters that create signed IBIP-like indicia, must continue to have a unique, dedicated key pair in each remote PSD. If a single key pair was used, and an end user compromised just one of those devices, that key could be distributed widely and used to create millions of fraudulent postage indicia.
In 1Q2001, the USPS permitted the inventor to institute the key management plan under a three-month beta test, and later officially notified all IBI centralized postage vendors that they too could employ this approach. The net result is there will be far fewer public keys to maintain for the USPS verification operations, and it is considerably more practical to perform stand-alone verification. Despite these improvements, the inventor believes that the stand-alone verification system can be eliminated without degrading postage security.
Another problem with the self-verifying IBI indicium concept is that it does a poor job of protecting against the fraudulent use of copies of valid postage indicia. Duplicate mail pieces have the potential to create substantial dollar losses to the USPS, particularly when high postage value packages are involved. Let us consider the following fraud scenario. A shipper has 70 pounds of goods to ship to a client, and he wishes to use Priority Mail. Roughly speaking, the USPS charges about $110 to transport 70 pounds cross-country via Priority Mail. If the goods can be subdivided into smaller packages, the shipper could easily perform the following attack. The shipper would create a postage-bearing shipping label for 35 pounds (approximately $52 in postage). The shipper would then create a second copy of this label, either by using a photocopy process, by interrupting the printer in mid-stream, causing it to think it must reprint a second version from the data in the printer memory, or by using a commonly available software package, such as Adobe Exchange, to create a PDF image of the label (rather than a print image), and then to print the resulting PDF image file more than once. Note that PC-based postage indicia do not use any special inks (such as the fluorescent-traced red ink used in conventional postage meters), so they are particularly easy to replicate. The shipper would then divide the shipment into two 35-pound cartons and apply a postage label to each carton (one an original, and the other a copy).
This would effectively defraud the USPS of over $50. If a USPS inspector happened to intercept either package and perform a scan of the barcode portion of the postage indicium, the information would be consistent on each label. The amount of postage in human-readable and barcode format would match. The date would be reasonable. The destination ZIP +4+2 would match that on the physical destination address. The only way the verifier could detect the fraud is by intercepting both packages simultaneously and scanning them side-by-side. The inspector would hopefully notice that the ascending/descending balances (c.f. items 5 and 11 in Table 1) were the same in each indicium—a clear indication of fraud.
The USPS has seemingly discounted the impact of “copy fraud.” The USPS recognizes that, as with conventional postage, it can only perform spot statistical testing on the mail stream.
But the USPS has also been somewhat “envelope-centric” in their thinking. That is, the USPS feels that an attacker would find little value in sending two envelopes to the same destination, and that the dollar amount of fraud would be on the order of 34 cents. The inventor believes that the future of PC-based postage is not with envelopes, but with high value, expedited packages. Letter mail (e.g., correspondence, statements, and invoices) is being rapidly replaced with electronic communications, and in the not-too-distant future, packages will dominate the USPS environment. This trend is likely to be accelerated given the anthrax attacks of 3Q2001. Therefore, it is believed that the USPS is underestimating the dollar value of this fraud threat. The inventor believes that by modifying the postage indicium as discussed herein, copy fraud can be further reduced if not effectively eliminated.
This is an appropriate time to discuss the “uniqueness” of the information in indicia. As we have seen in the previous example, using the digitally signed ZIP+4+2 and cross checking this value with the ZIP+4+2 shown in the human readable address, is not a fool proof method to detect copy fraud. The ZIP+4+2 of a given delivery address is something that can appear in an indicium for a given account holder on many occasions. Insofar as the indicium is concerned it is not a particularly unique value. What is unique in the originally proposed and used USPS indicium as the combination of the account number, the ascending register, and the descending register (balance) for that account. For instance, the concatenation of these three values should always result in a unique numerical string in an indicium. Put another way, if one finds two indicia with the identical concatenated value, this is clear evidence that at least one indicium is fraudulent.
The descending register in a given postage account is simply the amount of postage available to create indicia. It is effectively the “remaining balance”. The ascending register is the lifetime sum of all postage indicia created within that account. When an indicium is created, the descending register is decremented by the indicium value and the ascending register is incremented. Eventually, the meter account will run out of funds (the descending register approaches zero) and the account hold can purchase more postage from the postal authority. A postal purchase results in a matching increase in the descending register. The ascending register is not impacted by a postage purchase.
One can see that for a given account, a given descending register (say $5.00) may occur many times over the lifetime of the account. However, a situation where the ascending register is $505 and the descending register is $104 will only occur once (if at all) in a given account lifetime. This is because the ascending register is ever increasing as the life of the meter goes on.
The USPS has based some portion of its fraud detection protocol on the “uniqueness” provided by the ascending/descending register combination for a given account. But as an index for uniqueness, this is a poor choice from an operation standpoint. The combination of the two register values does not result in a continuous number series. The registers are tracked to the 1/10th of a cent (a mil), and a typical minimum change in the register values is 340 mils (a 34 cent First Class postage indicium). The next indicium might be a high-postage-value package and result in a register change of 20000 mils ($20.00). Again, the combination of ascending/descending registers will be unique for a given account, but this “index of uniqueness” is far from optimal. The index will have large gaps in the number sequence, and the gap sizes will be variable.
A seventh problem that has contributed to the failure of the IBIP is the assumption that all printing-related problems could be controlled by “perfect” vendor software and therefore, a staunch refusal to offer a refund procedure for failed or partially-printed mail pieces. It should be stressed that PC-postage is different from printing other types of shipping labels (e.g., UPS or FedEx) in that misprints are, in effect, losses of “money.” If a shipper misprints a UPS shipping label from a shipping software package or web site, another one can be reprinted and placed on the package with no negative financial impact to the shipper. This is because the UPS business model charges the shipper when the package enters the UPS shipping stream and is scanned. The UPS label has no inherent “value” until it enters the UPS delivery system. The USPS, however, as do many postal agencies worldwide, assumes that the postage is paid before the package enters the shipping stream.
The current USPS refund procedures for misprinted mail pieces are overly strict and reflect a mindset formed over decades of supporting conventional meter technologies. Refunds are possible, but only if one presents a physical specimen. For instance, if a mailer creates a meter strip using a conventional postage meter (or prints the postage indicium directly on a mail piece), and decides not to use that postage indicium, the postage indicium can be taken to a local post office for a refund of anywhere from 90% to 100% of the postage value.
For PC-postage vendors, the procedures are somewhat different, although the criteria are the same. If the PC-postage user creates a readable mail piece (specifically, the postage indicium must be scannable), it may be submitted to the PC-postage vendor for a refund. The vendor, in turn, applies to the USPS for a refund. The overall process is complex, time-consuming, and very costly to operate. It also requires that USPS auditors make field visits to the PC-postage vendors to examine all of the physical specimens before the refund can be authorized.
If the end-user is unlucky enough to have attempted to print a mail piece that resulted in a deduction to the account balance, but has no physical evidence of this mail piece, the current USPS rules prohibit a refund. Unfortunately, this situation is not uncommon. The mail piece stock (e.g., label or envelope) can misfeed, causing only a portion of the indicium to print on the paper. Or if the PC is low on Graphic Display Interface (GDI) or memory resources, or has crashed for any reason, the printer driver may fail to render the two-dimensional barcode image. Or if the job is sent to a network printer, it is possible that another user/operator can flush the PC-postage print job by manipulating the printer queue or control panel, thus resulting in the unavailability of the specimen.
As discouraging as all the IBIP-related problems may seem, the inventor feels that PC-postage can be made viable by incorporating novel, yet easily implementable, design elements into the IBIP base design.